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(57) ABSTRACT 

A caching system and method are disclosed that allow for 
the caching of web pages that have dynamic content. The 
caching system and method utihze a cacheability analyzer 
that analyzes responses based on time, content, user 
identification, and macro hierarchy. The caching system 
only caches those responses having dynamic content that are 
deemed cacheable. The method for caching dynamic content 
includes identifying parts of a response to a request for 
dynamic content from a requestor and attributes associated 
with the parts. The attributes are examined to determine 
cache abiUty of the response. A cacheability is made based on 
the determination and the response may be cached based 
upon that cacheability determination. 

94 Claims, 10 Drawing Sheets 
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METHOD AND SYSTEM FOR 
AUTOMATICALLY CACHING DYNAMIC 
CONTENT BASED ON A CACHEABILFTY 
DETERMINATION 

COPENDING APPLlCAnON 

This application is a co-pending application filed on an 
even date herewith and assigned U.S. patent application Ser. 
No. 09/236,723, entidcd "CACHE OVERRIDE CONTROL 
IN A DYNAMIC CACHING APPARATUS/' The subject 
matter of the above-identified co-pending patent application 
is incorporated herein by reference. 

HELD OF THE INVENTION 

The present invention relates generally to data caching of 
web content on a network and, more specifically, to the 
caching of dynamic content in web pages in a web server. 

BACKGROUND OF THE INVENTION 

The Internet and the World Wide Web (WWW) provide 
intra-enterprise connectivity, inter-enterprise connectivity 
and apphcation hosting on a larger scale than ever before. By 
exploiting the broadly available and deployed standards of 
the Internet and the WWW, system users and designers can 
leverage a single architecture to biiild client/server applica- 
tions for internal use that can reach outside to customers, 
business partners and suppliers. 

FIG. 1 shows a commonly used network arrangement in 
which a plurality of local computer systems 200 in a local 
area network (LAN) may access a plurality of remote 
servers 100 through the Internet. Each remote server may be 
a web server (such as a Domino*^** web server, available 
from Lotus Development Corporation of Cambridge, Mass.) 
for providing a web site for access by local computer 
systems 200. Each web site normally further provides a 
plurality of web pages to be served to the local computer 
systems upon request. Each local computer system may 
access the remote web sites with web browser software. 

The WWW is a collection of servers on an IP (Internet 
Protocol) network, such as the Internet, an Intranet or an 
Extranet, that utilize the Hypertext Transfer Protocol 
(HTTP). Hereinafter, "Interact" will be used to refer to any 
IP network. HTTP is a known application protocol that 
provides users with access to files, which can be in different 
formats, such as text, graphics, images, sound, and video, 
using a standard page description language known as Hyper- 
text Markup Language (HTML). Among a number of basic 
document formatting functions, HTML allows software 
developers to specify graphical pointers on displayed web 
pages, commonly referred to as "hyperUnks," that point to 
other web pages resident on remote servers. Hyperlinks 
commonly are displayed as highlighted text or other graphi- 
cal image on the web page. Selection of a hyperlink with a 
pointing device, such as a computer mouse, causes the local 
computer to download the HTML associated with the web 
page from a remote server. The browser then renders the 
HTML into the displayed web page. 

Web pages accessed over the Internet, whether by a 
hyperlink, opening directly via an "open" button in the 
browser, or some other means, are commonly downloaded 
into the volatile cache of a local computer system. In a 
computer system, for example, the volatile cache is a high 
speed buffer that temporarily stores web pages from 
accessed remote web sites. The volatile cache thus enables 
a user to quickly review web pages that were already 
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downloaded, thereby eliminating the need to repeat the 
relatively slow process of traversing the Internet to access 
previously viewed web pages. This is called local caching. 

On the server side, the first web servers were merely 
5 HTTP servers that resolved universal resource locators 
(URLs) by extracting literally from the URL the path to a file 
that contained the needed page, and transmitting the page 
back to the browser. Such a server was very simple; it could 
only be used to access static pages. 

A "static*' page is a page which, each time it is requested 
and served to a requestor, has the same byte content. That is, 
it does not matter which requestor is requesting the page, 
when the requester is requesting the page, etc., the byte 
content of that page remains the same. By contrast, a 
"dynamic page" is a page which has byte content that may 
change depending upon the particular requester, when the 
page is being requested, etc. This will be discussed further 
below. 

It is important that web pages be served as quickly as 
possible, both to reduce the response time to a single user, 
and to increase the number of users that can be served 
concurrently. To improve the response time, caches are used 
by the Web server. Web server caches are used to store web 

^ page responses in a readily accessible memory location so 
that when the web page is requested by a user, the previously 
cached web page response can be retrieved from cache and 
served quickly to the user. 

Caching web page responses by the web server works 

30 quite well for web page responses having static content, i.e., 
content that doesn't change frequently. An example of a 
static web page is one, at a company's web site, comprising 
a compilation of text and graphics objects describing that 
company's history. 

35 In fact, classic web servers cache static pages quite 
effectively. Specifically, classic web servers serve web page 
responses, some of which are static, namely, responses 
comprising HTML from the file system. Each of the static 
responses has a modified date associated with it that is 

40 maintained by the file system. These pages are cached easily 
by the web server. The contents of the response and its 
associated modification date are simply stored in the cache. 
When a subsequent request is received by the server for that 
page, the server requests the latest modification date for that 

45 page from the file system and compares the latest modifi- 
cation date with the modification date associated with the 
cached response. If the latest modification date is the same 
as the modification date associated with the cached 
response, the cached response is served. If the latest modi- 

50 fication date is later than the modification date associated 
with the cached response, the cadied response is considered 
"stale" and a "fresh" response is retrieved and built by the 
web server for serving to the requesting user. The fresh 
response, along with its associated modification date, is 

55 cached to replace the stale response. This caching scheme 
saves the time that otherwise would have been spent to build 
requested pages which otherwise could have been cached 
using this classic caching scheme. 

However, newer web servers provide not only static web 

60 pages but also dynamic web pages, i.e., a page having byte 
content that may change depending upon the particular 
requester, when the page is being requested, etc. Examples 
of dynamic web pages are pages containing content from a 
number of different sources or pages having computed 

65 content. For example, a page may contain macros that 
compute content for the page, i.e., the page has "computable 
content". These macros may change the page content each 
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time the page is accessed. This makes it difiScull to cache time of day that the request is made, etc. "Dynamic** content, 

that page using the classic caching method described above. as used in the system and method of the present invention, 

(Macros, or formulas as they are named in Lotus Notes refers to content that has such dependencies. As can be 

software, are expressions that perform a function, such as readily seen, using caching as a means for increasing server 

determinmg field values, definmg what documents appear in 5 performance for responses which have dynamic content has 

a view or calculate valu^ for a column^U)tus Notes is , j^^j^ber of complications and difficulties which have not 

available from Lotus Development Corporation in been overcome by any of the systems of the prior art. As 

Cambridge, Mass.) ^^^^^ WTML representing responses having dynamic con- 

Or, the page may contain infonnation from a number of tent has not been cached in the past. Accordingly, system and 

different sources, that information may or may not have 10 method to cache content that can include dynamic content 

associated modified dates making it difficult, if not without suffering from the drawbacks discussed above is 

impossible, to cache using the classic caching method. For needed, 
example, the page may comprise a composite of a number 

of "parts*' including: other documents, designs from SUMMARY OF THE INVENTION 

databases, content from databases, the present user's 15 According to the present invention, a caching system and 

identity, the current time, the current environment, etc. Some method utilized within a web server is disclosed that auto- 

of these parts are actual entities in the system, e.g., matically caches web content, such as web pages, that has 

documents, databases, etc. Some parts though arc "virtual" dynamic content. The caching system and method of the 

and are used to model the effects of the execution of macros present invention is utilized within a web server which 

or scripts, e.g., the user's identity may be accessed via one 20 receives requests for web pages and, based upon those 

of a number of ©functions such as @UserName, requests, serves web page re^onses that were previously 

@UserRoles, etc. in Lotus Notes software, ("©functions" cached or, if those cached responses are either inapplicable 

are macros for performing specialized tasks in Lotus Notes or invalid, the server builds a new response and serves it to 

formulas. They can be used to format text strings, generate the requester. The caching system performs two critical 

dates and times, format dates and times, evaluate conditional 25 functions: first, it determines the cacheability of built 

statements, calculate numeric values, calculate values in a responses and caches those responses it deems cache able 

list, convert text to numbers or numbers to text, or activate and second, if a cached response appears appropriate for a 

agents, actions, buttons, or hotspots.) These various part particular web page request, the caching system examines 

types are computable parts and have correspondingly vari- the cached response to determine whether the cached 

ous types of attributes that can not be handled by the classic 30 response is applicable for the particular request and whether 

caching systems and methods of prior art. the cached response is still valid. Each response is com- 

Qearly, it is more difficult to use caching as a mechanism prised of a plurality of parts, some of the parts being 

for improving user response time for pages with dynamic dynamic in nature. The parts have associated attributes that, 

content. This problem for the server is twofold. First, after either exphcitly or implicitly, characterize the nature of the 

building a web page response, the server must determine 35 parts. The caching system comprises an attribute analyzer 

whether the response that it is preparing to serve the request- that creates a composite set of attributes, the composite 

ing user is cacheable (i.e., determining its cacheability). representing the characteristics of the response. The caching 

Second, the server, upon receiving a request for a web page system further comprises a cacheabiUty analyzer that ana- 

whose previous response has been cached, must determine lyzes the attribute composite set and determines the cache- 

whether the cached response is valid (i.e., determining its 40 ability of the response. The server then caches the response 

validity) and applicable (i.e., determining its applicabiUty). based upon that determination. Examples of attributes uti- 

For instance, web page responses containing macros that are lized for determining cacheability include the time variance 

time -dependent may not be cacheable at all. If a page setting of the dynamic content, the user's identity, or the 

includes a macro for providing the current time, then every location of the content. 

access of the page is unique and the page cannot be cached 45 The caching system further comprises a cached-response 

in memory at all. Another example is where is a cached page analyzer for analyzing the cached responses prior to serving 

is valid for serving to some users but not others. For to a requesting user. The cached-response analyzer com- 

instance, if the page includes a macro for the user's name, prises an applicability analyzer (for determining the appli- 

then the page can be cached for the user's private access, but cability of the cached response to the particular request) and 

not for use by others. (HTML representing a document is 50 a validity analyzer (for determining the validity of the 

specific to a user if macros are dependent on user name or cached response). If the cached response passes the tests 

user roles. Using this user data, some data may be made performed by these analyzers it is served to the requesting 

visible based on which user is requesting it.) user. 

The term "Dynamic HTML" (DHTML) needs to be The method steps may also be implemented in program 

explained in the context of the method and system of the 55 code for modifying a computer system to cache information 

present invention. "Dynamic" in DHTML is referring pri- that has dynamic content. 

marily to the effect that the c=ode has on the web page gj^j^p DESCRIPTION OF THE DRAWINGS 

appearance at the browser. For instance, the dynamic HTML 

may comprise scripts which run on the browser to change foregoing and other objects and advantages of the 

the appearance of the web page such as by displaying a 60 invention wiU be appreciated more fully from the foUowing 

button which, if pushed, displays additional text or graphics. farther description thereof with reference to the accompa- 

The key distinction is that "dynamic" in the DHTML sense ^V^^^ drawings wherein: 

refers to the browser, not the server. From the server's point FIG. 1 is a block diagram of a generic network configu- 

of view, a DHTML page may still be "static" in that the byte ration that may be used with the disclosed system; 

content is the same each time the page is requested. The 65 FIG. 2 is a block diagram of a web server system; 

content is not dependent on any thing, e.g., the properties of FIG. 3 is a high-level block diagram of a Lotus Domino 

the request, such as the identity of the particular user, the web server; 
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FIG. 4 is a block diagram of a web server system having 
the caching system of the present invention; 

FIG. 5 (consisting of FIGS. Sa and Sb) is a flow chart of 
the method steps for determining the caching strategy when 
a document is being opened by a user; and 5 

FIG. 6 illustrates a flow diagram of the method steps for 
implementing the caching scheme according to the present 
invention. 

FIG, 7 (consisting of FIGS. 7a, 7b and 7c) is a flow chart 
illustrating the method steps for determining the applicabil- 
ity and validity of a cached response. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

FIG. 2 illustrates the system architecture for an exemplary 
server 100 or client computer 200, such as an IBM THINK- 
PAD 701® computer or like computer, on which the dis- 
closed network access system can be implemented. The 
exemplary computer system of FIG. 2 is discussed only for 
descriptive purposes, however, and should not be considered ^ 
a limitation of the invention. Although the description below 
may refer to terms commonly used in describing particular 
computer systems, the described concepts apply equally to 
other computer systems, including systems having architec- 
tures that are dissimilar to that shown in FIG. 2. 

The server 100 includes a central processing unit (CPU) 
205, which may include a conventional microprocessor, 
random access memory (RAM) 210 for temporary storage of 
information, and read only memory (ROM) 215 for perma- 
nent storage of information. A memory controller 220 is 
provided for controlling system RAM 210. A bus controller 
225 is provided for controlling bus 230, and an interrupt 
controller 235 is used for receiving and processing various 
interrupt signals from the other system components. 

Diskette 242, CD-ROM 247, or hard disk 252 may 
provide mass storage. Data and software may be exchanged 
with server 100 via removable media, such as diskette 242 
and CD-ROM 247. Diskette 242 is inserted into diskette 
drive 241, which is connected to bus 230 by controUer 240. 
Similarly, CD-ROM 247 can be inserted into CD-ROM 
drive 246, which is connected to bus 230 by controUer 245. 
CD-ROM 247 can also have digital versatile disc (DVD) 
playback capabilities as well. Finafly, the hard disk 252 is 
part of a fixed disk drive 251, which is connected to bus 230 45 
by controller 250. 

User input to the server computer 100 may be provided by 
a number of devices. For example, a keyboard 256 and a 
mouse 257 may be connected to bus 230 by keyboard and 
mouse controller 255. An audio transducer 296, which may 50 
act as both a microphone and a speaker, is connected to bus 
230 by audio controller 297. It should be obvious to those 
reasonably skilled in the art that other input devices, such as 
a pen and/or tablet and a microphone for voice input, may 
be coimected to server computer 100 through bus 230 and an 55 
appropriate controller. DMA controller 260 is provided for 
performing direct memory access to system RAM 210. A 
visual display is generated by a video controller 265, which 
controls video display 270. 

Server computer 100 also includes a network adapter 290 60 
that allows the server computer 100 to be interconnected to 
a network 295 via a bus 291. The network 295, which may 
be a local area network (LAN), a wide area network (WAN), 
or the Internet, may utUize general-purpose communication 
lines that interconnect a plurality of network devices. 65 

The Web server 100 answers URL (Universal Resource 
Locator) requests by sending back pages of data encoded in 



Hyper Text Markup Language (HTML). It also handles URL 
requests and HTML forms that trigger executable programs 
according to the Common Gateway Interface (CGI) speci- 
fication. The Web server 100 includes code that manages 
both inbound and outbound HTTP (Hyper Text Transfer 
Protocol) communications. In these respects, the Web server 
100 performs like any other HTTP server, responding in the 
standard way to standard URL requests. 

The preferred embodiment will be discussed primarily in 
terms of a Lotus Domino web server although the system 
and method of the present invention may be implemented in 
any web server. 

As a matter of background, as can be seen in its most basic 
form in FIG. 3, a Domino web server 100 is a server having 
many tasks running on it simultaneously. Among the server 
tasks are the Domino™ database server tasks 202, i.e., 
serving up documents from Domino databases 204, and the 
HTTP server tasks 206, i.e., serving up documents having 
formats such as HTML, GIF, JPEG, XML, DHTML, BMP, 
MPEG, WAV, Java applets, and other file formats known to 
those skilled in the art from file system 208. 

Notes software, available from Lotus Development 
Corporation, works with Domino to provide a distributed 
client/server database application to let users organize, 
process, track, and use information to suit their individual 
needs. Notes/Domino consolidate the tools needed to effec- 
tively communicate and collaborate in an organization by 
providing, inter alia, email, group discussion, workflow, 
scheduling, document management and many other func- 
tions. Domino databases are built on three basic concepts: 
documents, views and forms. Documents are collections of 
data items that can be retrieved as a set. Views are the ways 
of accessing the indices or summaries of documents stored 
in a database while forms are templates for accessing and 
displaying documents. 

When a Notes client 210 requests access to a Domino 
database 204 via the Notes network 212, the Domino 
database server task 202 provides access. When a web client 
200 requests an HTML document, the HTTP server task 206 
provides it. When a web client 200 requests a Notes 
document, the HTTP server task 206 passes the request 
through to the Domino database server task 202. If access is 
granted, the Domino database server 202 retrieves the 
requested document and passes it to an HTML converter 214 
which converts the Notes views, documents, and forms from 
Notes format to HTML format, then delivers the resulting 
HTML pages to the HTTP server 206 for serving to the web 
client. If a web client submits a form or query, the HTTP 
server task 206 passes the form to the HTML Converter 214 
which converts the form to Notes format and passes it to the 
Domino database server 202 for appropriate processing. 

FIG. 4 illustrates the server caching system in greater 
detail. As shown in FIG. 4, the web server 100 may be 
connected to a number of Domino sources 204. However, 
the sources may comprise any number of different types of 
elements, other than Domino databases: other databases, 
files, other web sites, etc, but Domino sources are shown for 
clarity. The web server may also be connected to HTML 
databases 208 as was discussed above. The web server 100 
comprises many functional units. It comprises the HTTP 
server 206, discussed above, which comprises a TCP/IP 
application 301, and a HyperText Transfer Protocol (HTTP) 
unit 302. The web server 100 further comprises the HTML 
converter unit 214 discussed above. It further comprises a 
parser 303 (for parsing received URLs), a cache 304, cache 
control unit 311, a cached-response analyzer 306, a response 
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builder 307, a source access unit 308 (or Domino database 
server 202) and a cacheability analyzer 309. 

These units operate as follows: TCP/IP unit 301 and 
HTTP unit 302 act together as the interface to the Internet by 
implementing the TCP/IP and HTTP protocols for server 5 
100. TCP/IP unit 301 utilizes the TCP/IP protocol for 
conveying and receiving information to and from the Inter- 
net. HTTP unit 302 implements HTTP, which is the standard 
on which the Web operates. These two units provide the 
full-service interface to the Web. lo 

When server 100 receives a URL from a client, the HTTP 
server 206 passes the URL to the URL Parser 303, which 
breaks the URL into different parts. The parsed URL is 
passed to the cache control unit 311. With a Domino server, 
within the URL that is received from the requesting user is 
a Domino/Notes-specific command, which indicates what 
action is being requested. The following are examples of 
server specific commands within the URL that may be 
received by the Domino server: 

?OpenDatabase — coimnand for opening a database; 

VOpenView — command for opening a view; 

?OpenDocxunent — command for opening a document; 

?OpeDForm — command for opening a form; 

?ReadForm — command for reading a form; and 25 

?EditDocument — command for editing a document. 

While, in this example, each of these commands has a "?" 
in front of the command as syntax that the server can use to 
identify the string as a command, the server can identify 
other syntaxes as well. These commands require a response 30 
to be sent to the requesting iiser. The requested response may 
have already been cadied and it may be valid and applicable. 
For those URLs having commands requesting a possibly- 
cached response (i.e., ?OpenDatabase, ? Open View, 
?OpenDocumeot, ?OpenForni, and VReadForm), the cache 35 
control 311 examines the request against previously cached 
responses to determine whether any of the previously cached 
responses is appropriate for the request. It does this by 
comparing the parsed URL against the URLs of the previ- 
ously cached responses in the cache 304. If there is not an 40 
exact match or if the URL doesn't have "cache able" com- 
mands (e.g., ?EditDocument), the parsed URL is passed to 
the response builder 307. The response builder 307 uses the 
parsed URL to build the response by accessing the appro- 
priate sources (via source access unit 308) and retrieving the 45 
appropriate "parts" to construct the response. The parts 
retrieved by the response builder 307 may comprise many 
different types, including data, forms, subforms, database 
design elements, calculations, etc. In other words, there is no 
theoretical restriction as to the type of parts comprising a 50 
web page re^onse. These parts each have their own 
attributes. For instance, some parts may or may not have last 
modified dates associated with the part. This wiU be dis- 
cussed in greater detail below. The attributes of all of the 
parts used to build the response are collected and analyzed 55 
by attribute analyzer 313. The attribute analyzer 313 builds 
a "composite" of the attributes, the attribute composite being 
representative of the entire response. 

Once the web page response is built by the response 
builder 307, it is passed to the HTML unit 305 for conver- 60 
sion to HTML. This HTML response is then passed to the 
HTTP server 206 for serving to the requesting user. 

At the same time, the attribute analyzer 313 passes the 
composite of the parts attributes to the cacheabiUty analyzer 
309 for determining the cacheability of the built response. 65 
The cacheability analyzer 309 examines the attribute com- 
posite and, if it determines that the response cannot be 
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cached, the response is not cached. If it determines that the 
response can be cached, it provides an indication to the 
cache control unit 311, along with the response and an 
associated set of cache strategy indicators generated by the 
cacheability analyzer 309. These indicators are used by the 
cached-response analyzer discussed below. The cacheability 
analyzer 309 comprises a cacheability analyzer interface 320 
and a caching strategy generator 322, The cacheability 
analyzer interface 320 acts as an interface for the cacheabil- 
ity analyzer 309 while the caching strategy generator 322 
examines the attribute composite and creates a caching 
strategy. 

If the cache control unit determines that there is an exact 
match between the parsed URL of the user request and the 
URLs corresponding to one of the cached responses in the 
cache 304, the cached response along with its associated 
cache strategy indicators is passed to the cached response 
analyzer 306. The response analyzer 306 performs two 
series of tests. The first series of tests are response-specific 
and the second series of tests are request-specific. The 
response-specific tests are performed by the validity ana- 
lyzer portion 315 while the request-specific tests are per- 
formed by the applicability analyzer portion 317. These tests 
will be discussed in greater detail below. If the cached 
response and its associated attributes pass the two tests, the 
cached response is simply served up to the user via the 
HTTP server 206. 

Determining how to make an accurate and timely decision 
as to which Web pages are cacheable is important in any 
caching system. Prior caching systems considered the pres- 
ence of macros, among others, too volatile, and thus, did not 
consider any pages with macros, for example, as candidates 
for caching. Unfortunately, this meant that many Web pages 
could not take advantage of caching and the performance 
gains that it provides. The caching system of the present 
invention improves performance in the server 100 by pro- 
viding the ability to cache Web pages that contain macros 
and other dynamic content. 

As mentioned above, each of the parts that comprise a 
response has attributes, which provide information about 
that particular part. These attributes can provide information 
about the part's identity and last modification date, as 
examples. This type of information is valuable to the cach- 
ing system of the present invention because it can be used to 
determine \h& cacheability, the applicability and the validity 
of the response or subsequentiy cached response. During the 
response bmlding process of the response builder 307, the 
attribute analyzer 313 collects the attributes of the parts used 
in building the response. The attribute analyzer 313 creates 
a composite of the attributes of the parts of the response so 
that the response has a composite of attributes representative 
of the entire response. The attribute composite set is passed 
to the cacheability analyzer 309. The cacheability analyzer 
309 uses this to determine a caching strategy. Specifically, 
the cacheability analyzer 309 examines the attribute com- 
posite and creates caching strategy flags which are used by 
the system for caching as will be discussed in greater detail. 

As was noted above, each "part" of the response may have 
one or more attributes. If the part is an @fimction, the 
following list corresponds each ©function with its associ- 
ated attribute(s) that are set at compute time. The attribute 
Depends means that the evaluation of the ©function will 
determine the attribute. If the ©function says "Fallback", 
that means that there is an evaluation that is Web server- 
specific and this is the non-Web version. Its converse is 
"Web." 
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©Accessed— OffDatabase, UsedDocld 
©Certificate — OfiTOatabase 
@ Command- Web — Depends 

@Coinmand([Compose]) — ^Depends, DbDesign, OffData- 
basc 

@Command([FileSave])— HadEffect 
©Created— UsedDocld 

©DbColumn-Fallback — UserVariant, DbDesign, DbData, 

Unknown, Depends, OSDatabase 
©DbCommand-Fallback — ^Unknown 
@DbCommand-Web — Depends 

@DbLookup-Fallback — Depends, Unknown, DbData, 

DbDesign, UserVariant, OflODatabase 
©DbManager — DbDesign 
©DbTitle— DbDesign 
@DocuinentUniqueID — ^UsedDocld 
©Environment — ^HadEffect, UsedEnvironment 
©GelDocField — DbData, UserVariant 
©GetPortsList — ^UsedEnvironment 
©GetProfileField— DbData, UserVariant 
©InheritedDocumentUniquelD — UsedDocld 
@M a il En cr y p tS a vedP reference -Fallback — 

UsedEnvironment 
©MailEncryptSentP reference -Fallback — 

UsedEnvironment 
©MailSavePreference -Fallback — UsedEnvironment 
©MailSend-Failback— HadEffect 
©MailSignPreference -Fallback — UsedEnvironment 
©Modified — ^UsedDocld 
©NotelD— UsedDocld 
©Now — Time Variant 
©PostedCommand-Web — Depends 
©Random — OffDatabase 
©Responses — DbData 
©SetDocField— HadEffect, UserVariant 
©SetProfilcField— HadEffect, UserVariant 
©TextToTime — Time Variant 
©Today — Time Variant 
©Tomorrow — ^Time Variant 
©Unique — None, Depends, OffDatabase 
©URLGetHeader-FaUback— OffDatabase 
©URLOpen-Fallback— OffDatabase, HadEffect 
©UserAccess-Web — OffDatabase, UserVariant, DbDesign 
©UserName — ^UserVariant 
©UserPrivileges — ^DbDesign, UserVariant 
©UserRoles-Fallback — DbDesign, UserVariant 
©UserRoles-Wcb — DbDesign, UserVariant 
© V3UserN ame — UserVariant 
©MewTitle — DbDesign 
©Yesterday — ^Time Variant 
©Zone — Time Variant 

The attribute composite used for characterizing the 
response for cacheability comprises the following attributes 
described below: 

OffDb — ^The response uses data outside the current data- 
base. This includes the use of CGI variables. 

TuncVariant (CacheUntil) — If the TimeVariant attribute 
bit is set, the response uses time-variant data (such as 
©Now which generates the current time and date). The 
CacheUntil parameter indicates the time/date after 
which the part is stale. 

HadEffect — ^The response has an important side-effect 
(such as ©SelDocField which modifies data in a 
Domino database), 

UsedEnv— The response uses the server environment (as 
found in the NOTES.INI file). This does not include 
CGI variables. 
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UserVariant — ^The response is dependent on the user's 
identity. This includes using any data or design note 
that includes Read ACLs (Access Control Lists), Read- 
ers fields. Authors fields or controlled access sections. 

DesignUserVariant — ^The response is from a database that 
has protected design elements. 

DbData — ^The response uses data in the database other 
than the referenced document. This includes all views, 
embedded views in forms, and so on. 

UsedDocld — ^The response uses the document's ID. 

UsedNewDoc — The response uses a newly -created 
in-memory note. 

Unknown — ^The response does something that couldn't be 
analyzed (such as executed in another programming 
language, such as LotusScript). 

Error — ^The response generated an error of some sort. 

This attribute composite is passed to the cacheability 
analyzer 309. It should be noted that this is the composite set 
of attributes for the response. The parts of the response 
contribute to this set by contributing to none, some or all of 
these attributes. The creation of the attribute composite set 
follows a conservative approach, Le., if one part has an 
attribute indicating that the part cannot be cached, the 
composite wiU indicate that the response cannot be cached. 

A number of caching strategy flags are generated by the 
cacheability analyzer 309 based upon the response attribute 
composite and are discussed below. It should be noted that 
this is a limited set of flags and other flags could be 
generated as weU and the system of the present invention is 
not so limited. The flags are: 

DontCache — Don't cache the response at all. 

Docimient — Invalidate the cached response when the 
document changes. 

DbDesign — Invalidate the cached response when the 
database design changes. 

DbData — ^Invalidate the cached response when any of the 
data in the database changes. 

OnlyAnonymous — Cache the response, but only serve it 
when the user is anonymous. 

FIG. 5 (comprising FIGS. 5a and Sb) is a flow chart that 
illustrates the method used by the cacheability analyzer 309 
to create the caching strategy flags associated with each of 
the built responses. This is the caching strategy used when 
the ?OpenDocument command is in the URL. Other caching 
strategies may be used when other commands are received 
from the user. At 400, the caching strategy procedure for an 
?OpenDocument command begins. At 402, the attribute 
composite is received by the cacheability analyzer 309 (via 
cacheabihty analyzer interface 320 and is passed to caching 
strategy generator 322) from the attribute analyzer 313. At 
404, in the caching strategy generator 322, the Document 
strategy flag is set. (For purposes of clarity, "to set" when 
used in conjunction with the state of a particular flag means 
to change it to "1", or positive state, while "to reset" means 
to change il to *'0", or negative state.) At 406, the OffDb 
attribute is examined. If it is set, the DontCache strategy flag 
is set at 408. After the DontCache strategy flag is set at 408, 
the procedure goes to "A" shown on FIG. 5b. At "A", the 
procedure is finished at 434.) At 406, if the OffDb attribute 
is not set, the HadEffect attribute is examined at 410. If it is 
set, the DontCache strategy flag is set at 408 and the 
procedure continues to "A"' as discussed above.) At 410, if 
the HadEffect attribute is not set, the limeVariant attribute 
is examined at 412. If it is set, the CacheUntil parameter 
(whidi accompanies the TimeVariant attribute) is examined 
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at 413. The CacheUntil parameter is in time/date units FIG. 6 is a flow chart illustrating the method implemented 

indicating the time/date after which the part (or response) is in the cacheability analyzer interface 320. At 500, the 

stale. This parameter is especially useful for the retrieval cacheability analyzer interface 320 receives the caching 

portion of this system to be discussed below. If the Cache- strategy flags from the caching strategy generator 322. At 

Until parameter is earber than the then-present system s 502, the DontCache flag is examined. If it is set, the response 

time/date, the DontCache strategy flag is set at 408 aj,d the ^^hout the strategy flags is served to the HTTP server 206 

?h^^tLt'^f ™^ as discussed above At 413, if ^^^out being cached at 504. If it is not set, the response 

^vtt.^Si n^^^^ I T^' v'"" (after it has been converted to HlTvlL), along with the 

system tune/date or, at 413, the TimeVanant attribute IS not oi^^t^™,, a.^o ™+u ^ ,u , / . 

set, the UsedDocId attribute is examined at 414. If it is set, f ^f' "f, f xTrn !' P'^'^^t'^ 1'^^*^ f 

the UsedNewDoc attribute is examined at 416. If it is set last^odified.date CacheUntil) etc.), is sent to the cache 

(i.e., both the UsedDocid and UsedNewDoc attributes are ^^^"^^ response is also served back to 
set), the DontCache strategy flag is set at 408 and the 

procedure continues to **A'' as discussed above. If either the ^ response is cached, it remains m the cache until it 

UsedDocId or the UsedNewDoc attribute is not set, the is either removed or replaced. A cached response is normally 

UserVariant attribute is examined at 418, If it is not set, the replaced after it becomes known that one of the source parts 

DesignUserVariant attribute is examined at 420. If it is not been modified at the source. This is sometimes known as 

set, the procedure continues at "C to be discussed below. If the cached response becoming "stale". Normally, a cached 

either the UserVariant attribute at 418 or the DesignUser- response is identified as stale when its URL is requested by 

Variant attribute at 420 is set, the procedure continues at "B" a user and the cache control unit compares the cached 

in FIG. 5b. 20 response's last modified date against the all of the source 

At "B" in FIG. 5b, the cacheability analyzer 309 deter- parts' last modified dates as discussed above, 

mines whether the USER_AUTHENnCArED bit is set at A cached response may be removed for any number of 

422. The USER_AUTHENn GATED bit, which is a prop- reasons defined by the cache designer. Many times, the 

erty of the request that is determined during the initial cache control unit 311 comprises a cache manager which 

processing of the request, indicates that the user was authen- 25 utilizes a cache management utility for managing the cache, 

ticated by the server. If the user was not authenticated and The cache manager may, for example, remove from cache 

was still allowed to access the server data, the user is logged those cached responses that have a predetermined life span 

on as "Anonymous", There are many reasons why a server which has expired (e.g., a response may have a CacheUntil 

may be designed to authenticate a user. One reason may be parameter associated with it) or those cached responses that 

that the authenticated user is allowed to access areas of the 30 have least frequently been accessed (when the cache is 

web site not accessible to non-authenticated users. Another getting fuU, for instance). 

may be that the authenticated user is allowed to enter In any event, after a request is received, the request is 

information in databases where a non-authenticated user is examined by cache control unit 311 and the previously- 

not. In any event, the USER_AUTHENTICATED bit is cached responses are analyzed to determine whether any of 

passed to the cacheability analyzer 309 along with the 35 the cached responses are candidates for serving to the 

attribute composite. request. A cached response is a candidate is it is appropriate 

If USER_AUTHENTICATED bit is set, the DontCache to the request. Specifically, the received URL is parsed, 

strategy flag is set at 408 and the procediue continues to "A" examined for a suitable command request, e.g., 

as discussed above. If it is not set, the OnlyAnonymous "?OpenDocument", and compared against the cached 

strategy flag is set at 424. At 426 and at "C", the DbDesign 40 response URLs, A matching URL cached entry is analyzed 

strategy flag is set. At 428, the DbData attribute is examined. by the cached-response analyzer 306 as discussed above. 

If it is not set, the procedure ends at 434. If it is set, the Specifically, the caching strategy flags which were stored 

Document strategy flag is reset at 430. The DbData strategy along with the cached response are analyzed for applicabil- 

flag is then set at 432. The procedure then ends at 434, ity (via the applicability analyzer 317) and for validity (via 

FIGS, Sa and 5b and corresponding discussion relates 45 the validity analyzer 315). FIG. 7 is a flow chart illustrating 

only to the cacheability strategy procedure when the request both the applicability analysis method and the validity 

is an ?OpenDocumcnt request. If the request includes analysis method of a cached response, 

another command instead, such as VOpenView, the cache- FIG. 7 consists of FIGS, 7a, 7b and 7c. FIG. 7a lays out 

ability procedure may be different. However, this procedure the applicabiUty analysis procedure while 7b and 7c depict 

is exemplary of cacheability procedures for oflier com- 50 the procedure followed for the validity analysis. In FIG. 7a, 

mands. at 600, the caching strategy flags are examined by the 

Another point is that the CacheUntil parameter was applicability analyzer 317, At 602, the OnlyAnonymous 

discussed only in terms of the TimeVanant attribute for an strategy flag is examined. If it is not set, the applicability 

©function. The CacheUntil parameter could be used to procedure is successfully completed at "E", so that the 

characterize the part, irrespective if the part generated time/ 55 validity analysis procedure may begin. If it is set, at 604, the 

date data as the ©functions having the TimeVanant USER_AUTHENnCATED bit for the cunent request is 

attribute. It could be used to indicate a future lime/date that examined. If the USER__AUTHENnCArED bit is not set, 

the part was expected to change, after which the cached the applicabflity procedure is successfully completed at "E", 

response having that part should be re-built. so that the validity analysis procedure may begin. If it is set, 

The caching strategy flags that are generated by the 60 the applicability procedure is completed at 608 but has 

caching strategy generator 322 are passed to the cacheability failed. After a failed completion of the applicability 

analyzer interface 320. The cacheability analyzer interface procedure, there is no need to continue with the validity 

320 examines the flags to determine whether the built analysis as the cached response is not returned to the user, 

response should be cached in cache 304. Concurrently, the At 608, a request is made to the response builder 307 to build 

built response is sent to the HTML unit 214 and to the HTTP 65 a new response based upon the requested URL. 

server 206. The HTTP server 206 serves the built response The applicability analysis portion of the cached-response 

in HTML format to the user (without the strategy flags). analysis only examined, as an example, one strategy flag 
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(OnlyAnonymoixs). However, there are other request- with many computer architectures or operating systems, 

specific characteristics that could as easily be tested. Tests Furthermore, such instructions may be stored in any 

for appropriate browser type and version, and tests for the memory device, such as semiconductor, magnetic, optical or 

appropriate language are examples of other user-specific other memory devices, and may be transmitted using any 

tests that may be run against a cached response to ensure that s communications technology, such as optical, infrared, 

it is applicable to the request or the requesting user. microwave, or other transmission technologies. It is 

In FIGS. 7fc and 7c, the validity analysis begins at "E". At expected that such a computer program product may be 

610, the Document strategy flag is examined. If it is not set, distributed as a removable media with accompanying 

the procedure moves to 612. If it is set, the last modified date P^^^^^^ electronic documentation (e.g., shrink wrapped 

of the candidate cached response document is compared lO f'^^^'n^V' « . ' ^""^^"^u ^1^^^ " '''' 

against the last modified date of the source document at 614. • k^u^'k 'f^' or distributed from a server or 

tF *u 1 . j £ J J * ^ 1 xi_ J J . electronic bulletin board over the network (e.g., the Internet 

It the last modified dates are not equal, the candidate World Wide Web^l 

response is "stale- and the procedure moves to which Although various exemplary embodiments of the inven- 

contmues at 608. If the dates are equal, at 612, the DbDesign ^ave been disclosed, it will be apparent to those skilled 

strategy flag is examined. If it is not set, the procedure 15 fn the art that various changes and modifications can be 

moves to 620. If it is set, the last modified date of the made that will achieve some of the advantages of the 

candidate cached response database is compared against the invention without departing from the true scope of the 

last modified date ofthe source database design at 618. If the invention. These and other obvious modifications are 

last modified dates are not the same at 619, the candidate intended to be covered by the appended claims, 

response is "stale" and the procedure moves to "F" which 20 Having thus described the invention, what we desire to 

continues at 608. If the dates are the same, at 620, the claim and secure by Letters Patent is: 

DbData strategy flag is examined. If it is not set, the 1. A system for caching which receives a request from a 

procedure moves to "G" which continues at 626. If it is set, requester and builds, by collecting one or more parts from 

the last modified date of the candidate cached response is one or more sources, a response to that request, the response 

compared against the last modified date of any of the data in 25 comprising a composite of the one or more parts, at least one 

the source database design at 622. If the last modified dates comprising dynamic content, each part having 

are not the same at 624, the candidate response is "stale" and ™°^e attributes characterizing the part, the attributes 

the procedure moves to "F" which continues at 608. If they indicating the cacheability of the part, the system for caching 

are the same, at "G" which continues at 626, the CacheUntil ^® response comprising: 

date is examined. If it is earlier than the present system 30 an attribute analyzer for determinmg the attributes of the 

time/date, the response is "stale" and the procedure moves parts of the a response; 

to "F* which continues at 608. If it is equal to or later than cacheabihty analyzer for examining the attributes to 

the present system time/date, at 626, the candidate cached determine cacheabihty of the response, wherein the 

response is both applicable and valid and is returned to the attributes include at least one of a time variance setting 

HTTP server 206 for serving to the user. 35 of dynamic content, a user's identify, or a location of 

It should be understood, however, that use of the hyper- dynamic content, and making a cacheability determi- 

text server may be practiced with other types of remote nation based upon that examination; and 

documents, such as word processor or spread sheet docu- means for caching the response based upon that cache- 

ments. Accordingly, maintenance of a database is discussed abifity determination. 

here for exemplary purposes and is not intended to limit its 40 2. The system of claun 1 wherein the dynamic content 

scope. It also should be noted that although many embodi- comprises a computable part. 

ments of the system have been discussed with reference to 3. The system of claim 1 wherein the attribute analyzer 
World Wide Web pages, the system may be practiced with creates a composite set of attributes based upon the indi- 
various other types of documents. Moreover, although a vidual attributes of the individual parts, the composite 
Lotus Domino web server environment is disclosed as the 45 attribute set providing a characterization of the cacheability 
preferred embodiment, it should be understood that the of the response; and fiirther wherein the cacheability ana- 
disclosed system may be utilized with any known web lyzer examines the attribute composite set to determine the 
server. The above discussion of Domino and Notes was cacheability of the response. 

exemplary only and therefore should not be considered a 4, The system of claim 1 wherein the cacheability ana- 
limitation of the caching system. so lyzer creates a caching strategy comprising a plurality of 

In an alternative embodiment, the system may be imple- flags, 

mented as a computer program product for use with a 5. The system of claim 4 wherein each request has one or 

computer system. Such implementadon may include a series more properties, wherein the cacheabihty analyzer creates a 

of computer instructions fixed either on a tangible medium, caching strategy comprising at least one flag indicating that 

such as a computer readable media (e.g., diskette 242, 55 the response is cache able and at least one flag indicating that 

CD-ROM 247, ROM 215, or fixed disk 252 as shown in the applicability of the response for serving to subsequent 

FIG. 2) or transmittable to a computer system, via a modem requests is based upon the one or more properties of the 

or other interface device, such as communications adapter subsequent request, 

290 connected to the network 295 over a medium 291, 6. The system of claim 5 wherein one of the request 

Medium 291 may be either a tangible medium (e.g,, optical 60 properties is the identity of the requester, wherein the 

or analog communications Unes) or a medium implemented caching strategy comprises at least one flag indicating that 

with wireless techniques (c,g,, microwave, infrared or other the response is cacheable and at least one flag indicating that 

transmission techniques). The series of computer instruc- the applicability of the response for serving to subsequent 

tions embodies all or part of the functionality previously requestors is based upon the subsequent requestor identity 

described herein with respect to the system. Those skilled in 65 property. 

the art should appreciate that such computer instructions can 7. The system of claim 5 wherein one or more of the 

be written in a number of programming languages for use request properties is the characteristics of the requestor's 
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browser, wherein the caching strategy comprises at least one determination further comprises at least one flag indicating 

flag indicating that the response is cacheable and at least one that the response is cacheable and further comprises at least 

flag indicating that the applicability of the response for one flag indicating that the applicability of the response for 

serving to subsequent requesters is based upon flie subsc- serving in response to a subsequent request is based upon the 

quent requester browser characteristic properties. s one or more properties of the subsequent request. 

8. The system of claim 5 wherein one of the request 18. The method of claim 17 wherein one of the request 
properties is the requested language, wherein the caching properties is the identity of the requester, wherein the 
strategy comprises at least one flag indicating that the cache ability determination comprises at least one flag indi- 
response is cacheable and at least one flag indicating that the eating diat the response is cacheable and at least one flag 
applicability of the response for serving to subsequent lO indicating that the applicability of the response for serving 
requests is based upon the requested language property of to subsequent requesters is based upon the subsequent 
the subsequent request. requester identity property. 

9. The system of claim 4 wherein the caching strategy 19. The method of claim 17 wherein one or more of the 
comprises at least one flag indicating that the response is request properties is the characteristics of the requestor's 
cacheable but its validity is based upon whether any of the 15 browser, wherein the cacheability determination comprises 
parts on the one or more sources has been modified since the at least one flag indicating that the response is cacheable and 
response has been cached, at least one flag indicating that the applicability of the 

10. The system of claim 1 wherein the cacheability response for serving to subsequent requesters is based upon 
analyzer analyzes the attributes to determine whether any of the subsequent requester browser characteristic properties, 
the attributes indicate that the response causes important 20 20. The method of claim 17 wherein one of the request 
side effects and makes a determination that the response is properties is the requested language, wherein the cacheabil- 
not cacheable if any of the attributes indicate that the ity determination comprises at least one flag indicating that 
response causes important side effects. the response is cacheable and at least one flag indicating that 

11. The system of claim 1 wherein the cacheabflity the applicabiUty of the response for serving in response to 
analyzer analyzes the attributes to determine whether any of 25 subsequent requests is based upon the requested language 
the attributes indicate that the response uses time variant property of the subsequent request. 

data and makes a determination that the response is only 21. The method of claim 16 wherein the cacheability 

cacheable for a determined length of time if any of the determination further comprises at least one flag indicating 

attributes indicate that the response uses time variant data. that the response is cacheable and at least one flag indicating 

12. The system of claim 1 wherein the cacheability 30 that the validity of the response for serving to subsequent 
analyzer further comprises means for creating a caching requests is based upon a determination of whether any of the 
strategy comprising a plurality of flags, and further wherein parts on the one or more sources has been modified since the 
the means for caching caches the caching strategy flags response was cached. 

along with the associated response. 22. The method of claim 13 wherein step b further 

13. In a system which receives a request from a requestor 35 comprises analyzing the attributes to determine whether any 
and dynamically builds, by collecting one or more parts of the attributes indicate that response causes important side 
from one or more sources, a re^onse to that request, the effects and wherein step c further comprises making a 
response comprising a composite of the one or more parts, determination that the response is not cacheable if any of the 
at least one of the parts comprising dynamic content, each attributes indicate that response causes important side 
part having one or more attributes characterizing the part, 40 effects. 

the attributes indicating the cacheability of the part, a 23. The method of claim 13 wherein step b further 

method for caching the response comprising the steps of: comprises analyzing the attributes to determine whether any 

a) identifying the parts of the response and their associ- attributes indicate that the response uses time variant 
ated attributes, wherein the attributes include at least ^^^^ wherein, in step c, the cacheability determination 
one of a tune variance setting of dynamic content, a 45 comprises at least one flag for indicating that the response is 
user's identify, or a location of dynamic content; cacheable and is valid for serving to subsequent requests for 

b) examining the attributes to determine cacheability of ^ d^t^nnined length if any of the attributes indicate that 
the response; and response uses time variant data^ 

... , , M- ^ . . . , . 24. Ine method of claim 13 wherem step c further 

c) makmg a cacheability determination based upon that comprises the step of creating a caching strategy comprising 
exammaUon, and ^ plurahty of flags, and further wherein step d caches the 

d) cachmg the response based upon the cacheability caching strategy flags along with the associated response, 
determination. 25. A computer usable medium, for use in a computer 

14. The method of claim 13 wherein the dynamic content which receives a request from a requestor and dynamicaUy 
comprises a computable part. 55 b^iids, by coUecting one or more parts from one or more 

15. The method of claim 13 further comprising, after step sources, a response to that request, the response comprising 
a, the step of: ^ composite of the one or more parts, at least one of the parts 

al. creating a composite set of attributes based upon the comprising dynamic content, each part having one or more 

individual attributes of the individual parts, the com- attributes characterizing the part, the attributes indicating the 

posite attribute set providing a characterization of the go cacheability of the part, the computer usable medium having 

cacheability of the response; and computer readable program code embodied in the medium 

in step b, examining the attribute composite set to deter- for causing the computer to perform method steps for 

mine cacheability of the response. caching the response comprising the method steps of: 

16. The method of claim 13 wherem, in step c, the a) identifying the parts of the response and then assod- 
cacheability determination comprises a plurality of flags. 65 ated attributes, wherein the attributes include at least 

17. The method of claim 16 wherein each request has one one of a time variance setting of dynamic content, a 
or more properties, wherein, in step c, the cacheability user's identify, or a location of dynamic content; 
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b) examining the attributes to determine cacheability of 
the response; and 

c) making a cacheability determination based upon that 
examination; 

d) caching the response based upon that cacheability s 
determination. 

26. The computer usable medium of claim 25 wherein the 
dynamic content comprises a computable part. 

27. The computer usable medium of claim 25 further 
comprising, after step a, the step of: 

al. creating a composite set of attributes based upon the 
individual attributes of the individual parts, the com- 
posite attribute set providing a characterization of the 
cacheability of the response; and 

in step b, examining the attribute composite set to deter- 15 
mine cacheability of the response. 

28. The computer usable medium of claim 25 wherein, in 
step c, the cacheability determination comprises a plurality 
of flags. 

29. The computer usable medium of claim 28 wherein 20 
each request has one or more properties, wherein, in step c, 
the cacheability determination further comprises at least one 
flag indicating that the response is cacheable and further 
comprises at least one flag indicating that the applicability of 
the response for serving in response to a subsequent request 25 
is based upon the one or more properties of the subsequent 
request. 

30. The computer usable medium of claim 29 wherein one 
of the request properties is the identity of the requester, 
wherein the cacheability determination comprises at least 30 
one flag indicating that the response is cacheable and at least 
one flag indicating that the applicability of the response for 
serving to subsequent requesters is based upon the subse- 
quent requester identity property. 

31. The computer usable medium of claim 29 wherein one 35 
or more of the request properties is the characteristics of the 
requestor's browser, wherein the cacheability determination 
comprises at least one flag indicating that the response is 
cacheable and at least one flag indicating that the applica- 
bility of the response for serving to subsequent requesters is 40 
based upon the subsequent requestor browser characteristic 
properties. 

32. The computer usable medium of claim 29 wherein one 
of the request properties is the requested language, wherein 
the cacheability determination comprises at least one flag 45 
indicating that the response is cacheable and at least one flag 
indicating that the applicability of the response for serving 

in response to subsequent requests is based upon the 
requested language property of the subsequent request. 

33. The computer usable medium of claim 28 wherein the 50 
cacheability determination further comprises at least one 
flag indicating that the response is cacheable and at least one 
flag indicating that the validity of the response for serving to 
subsequent requests is based upon a determination of 
whether any of the parts on the one or more sources has been 55 
modified since the response was cached. 

34. The computer usable medium of claim 25 wherein 
step b further comprises analyzing the attributes to deter- 
mine whether any of the attributes indicate that response 
causes important side effects and wherein step c further 60 
comprises making a determination that the response is not 
cacheable if any of the attributes indicate that response 
causes important side effects. 

35. The computer usable medium of claim 28 wherein 
step b further comprises analyzing the attributes to deter- 65 
mine whether any of the attributes indicate that the response 
uses time variant data and wherein, in step c, the cacheability 
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determination comprises at least one flag for indicating that 
the the response is cacheable and is valid for serving to 
subsequent requests for a determined length if any of the 
attributes indicate that response uses time variant data. 

36. The computer usable medium of claim 25 wherein 
step c further comprises the step of creating a caching 
strategy comprising a plurality of flags, and further wherein 
step d caches the caching strategy flags along with the 
associated response. 

37. In a system for receiving requests from requestors and 
serving responses to those requests, the system having a 
cache for holding previously served responses for serving to 
subsequent requests, at least some of the responses com- 
prising dynamic content, a cached response retrieval system 
for retrieving a cached response comprising: 

a cache control unit having means for receiving a request 
and means for determining whether the cache contains 
a candidate cached response appropriate for that 
request; 

a cached response analyzer for analyzing the candidate 
cached response, the cached response analyzer deter- 
mining the validity of the candidate cached response; 

whereby the system serves the candidate cached response 
if the cached response analyzer determines that the 
candidate cached response is valid, wherein the validity 
of the candidate of the cache response is determined 
based on at least one of a time variance setting of 
dynamic content, a user's identity, and a location of 
dynamic content, 

38. The cached response analyzer of claim 37 wherein the 
cached response analyzer has an applicability analyzer for 
determining the applicability of the candidate cached 
response for serving to the request. 

39. The cached response analyzer of claim 38 wherein the 
request has request properties, one of the request properties 
being a language type, wherein the applicability analyzer 
determines whether the candidate cached response is apph- 
cable for serving to the request based upon the language 
type. 

40. The cached response analyzer of claim 38 wherein the 
request has request properties, one of the request properties 
being a browser type, wherein the applicability analyzer 
determines whether the candidate cached response is appli- 
cable for serving to the request based upon the browser type, 

41. The cached response analyzer of claim 38 wherein the 
request has request properties, one of the request properties 
being a requester identity, wherein the applicability analyzer 
determines whether the candidate cached response is appli- 
cable for serving to the request based upon the requestor 
identity. 

42. The cached response analyzer of claim 38 wherein the 
candidate cached response comprises caching strategy flags, 
wherein the cached response analyzer has a validity 
analyzer, wherein the applicability analyzer analyzes the 
caching strategy flags related to the request and the validity 
analyzer analyzes the caching strategy flags related to the 
response. 

43. The cached response analyzer of claim 37 wherein the 
system builds responses from parts from one or more 
sources, wherein the parts of each candidate cached response 
each has a last modified date, wherein the cached response 
analyzer has a validity analyzer for comparing the parts of 
the candidate cached response last modified dates to the last 
modified dates of the parts comprising the response on the 
one or more sources. 

44. The cached response analyzer of claim 37 wherein the 
system has a present system time/date indicating the present 
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time and date, wherein the candidate cached response com- 
prises a "cache until" time/date, wherein the cached 
response analyzer has a validity analyzer, wherein the valid- 
ity analyzer analyzes the "cache until" time/date against the 
present system time/date to determine whether the "cache 
until" time/date is earlier than the present system time/date. 

45. For use in a system for receiving requests from 
requestors and serving responses to those requests, the 
system having a cache for holding previously served 
responses for serving to subsequent requests, at least some 
of the responses comprising dynamic content, a method for 
retrieving a cached response comprising the steps of: 

receiving a request; 

determining whether the cache contains a candidate 

cached response appropriate for that request; 
analyzing a candidate cached response; and 
determining the validity of the candidate cached response, 
whereby the system serves the candidate cached 
response if, during step d, candidate cached response is 
determined valid, wherein the validity of the candidate 
of the cache response is determined based on at least 
one of a time variance setting of dynamic content, a 
user's identity, and a location of dynamic content. 

46. The method of claim 45 wherein step d further 
comprises the step dl determining the applicability of the 
candidate cached response to the request. 

47. The method of claim 46 wherein the request has 
request properties, one of the request properties being a 
language type, step dl further comprises determining 
whether the candidate cached response is applicable for 
serving to the request based upon the language type, 

48. The method of claim 46 wherein the request has 
request properties, one of the request properties being a 
browser type, step dl further comprises determining 
whether the candidate cached response is applicable for 
serving to the request based upon the browser type. 

49. The method of claim 46 wherein the request has 
request properties, one of the request properties being a 
requestor identity, step dl further comprises determining 
whether the candidate cached response is applicable for 
serving to the request based upon the requestor identity. 

50. The method of claim 46 wherein the candidate cached 
response comprises caching strategy flags, wherein step d 
further comprises analyzing the caching strategy flags 
related to the response for validity and wherein step dl 
further comprises analyzing the caching strategy flags 
related to the request for applicability. 

51. The method of claim 45 wherein the system builds 
responses from parts from one or more sources, wherein the 
parts of each candidate cached response each has a last 
modified date and step d further comprises comparing the 
parts of the candidate cached response last modified dates to 
the last modified dates of the parts comprising the response 
on the one or more sources. 

52. The method of claim 45 wherein the system has a 
present system time/date indicating the present time and 
date, wherein the candidate cached response comprises a 
"cache until" time/date, wherein step d comprises analyzing 
the "cache until" time/date against the present system time/ 
date to determine whether the "cache until" time/date is 
earlier than the present system time/date. 

53. A computer usable medium for use in a computer for 
receiving requests from requesters and serving responses to 
those requests the computer having a cache for holding 
previously served responses for serving to subsequent 
requests, at least some of the responses comprising dynamic 
content, the computer usable medium having computer 
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readable program code embodied in the medium for causing 
the computer to perform method steps for retrieving a 
cached response comprising the method steps of: 
a) receiving a request; 
s b) determining whether the cache contains a candidate 
cached response 10 appropriate for that request; 

c) analyzing a candidate cached response; 

d) determining the validity of the candidate cached 
response, whereby the computer serves the candidate 

10 cached response if, during step d, the candidate cached 
response is determined valid, wherein the validity of 
the candidate of the cache response is determined based 
on at least one of a time variance setting of dynamic 
content, a user's identity, and a location of dynamic 

j5 content; and 

e) determining the applicability of the candidate cached 
response to the requestor. 

54. The computer usable medium of claim 53 wherein 
step d farther comprises the step dl determining the appli- 

20 cability of the candidate cached response to the request. 

55. The computer usable medium of claim 54 wherein the 
request has request properties, one of the request properties 
being a language type, step dl further comprises determin- 
ing whether the candidate cached response is applicable for 

25 serving to the request based upon the language type. 

56. The computer usable medium of claim 54 wherein the 
request has request properties, one of the request properties 
being a browser type, step dl further comprises determining 
whether the candidate cached response is applicable for 

30 serving to the request based upon the browser type. 

57. The computer usable medium of claim 54 wherein the 
request has request properties, one of the request properties 
being a requester identity, step dl further comprises deter- 
mining whether the candidate cached response is applicable 

35 for serving to the request based upon the requester identity. 

58. The computer usable medium of claim 54 wherein the 
candidate cached response comprises caching strategy flags, 
wherein step d further comprises analyzing the caching 
strategy flags related to the response for validity and wherein 

40 step dl further comprises analyzing the caching strategy 
flags related to the request for applicability. 

59. The computer usable medium of claim 53 wherein the 
system builds rci^onses from parts from one or more 
sources, wherein the parts of each candidate cached response 

45 each has a last modified date and step d further comprises 
comparing the parts of the candidate cached response last 
modified dates to the last modified dates of the parts com- 
prising the response on the one or more sources. 

60. The computer usable medium of claim 53 wherein the 
50 system has a present system time/date indicating the present 

time and date, wherein the candidate cached response com- 
prises a "cache until" time/date, wherein step d comprises 
analyzing the "cache xmtfl" time/date against the present 
system time/date to determine whether the "cache until'' 
55 time/date is earlier than the present system time/date. 

61. A system which receives a request from a requestor 
and serves a response to that request, the response compris- 
ing a composite of the one or more parts, at least one of the 
parts comprising dynamic content, the system comprising: 

60 means for receiving a request from a requestor; 

a cache for holding previously served cached responses; 

a cache control unit for comparing the request against 

the cached response and for identifying a candidate 

cached response; 
65 a cached response analyzer for determining whether the 

candidate cached response shotild be served to the 

request; 
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a response builder for a building response; 

a cache ability analyzer for analyzing the built response 
and determining its cacheabiUty, wherein the cache- 
ability is determined based on at least one of a time 
variance setting of dynamic content, a user's identity, 
and a location of dynamic content; means for caching, 
in the cache, the response based upon that cacheability 
determination; and 

means for serving the response or candidate cached 
response to the request. 

62. Tlie system of claim 61 wherein the cached response 
analyzer comprises an applicability analyzer for determining 
the apphcability of the candidate cached response to the 
request and a validity analyzer for determining the validity 
of the candidate cached response; 

whereby the serving means serves the candidate cached 
response if the cached re^onse analyzer determines 
that the candidate cached response is both applicable 
and valid. 

63. The system of claim 62 wherein the request has 
request properties, one of the request properties being a 
requester identity, wherein the applicability analyzer deter- 
mines whether the candidate cached response is apphcable 
for serving to the request based upon the requester identity. 

64. The system of claim 62 wherein the response builder 
builds responses from parts from one or more sources, 
wherein the parts of each candidate cached response each 
has a last modified date, wherein the cached response 
analyzer has a validity analyzer for comparing the parts of 
the candidate cached response last modified dates to the last 
modified dates of the parts comprising the response on the 
one or more sources. 

65. The system of claim 61 wherein cached response 
comprises caching strategy flags, wherein the cached 
response analyzer comprises an applicability analyzer for 
analyzing the caching strategy flags related to the request 
and a validity analyzer for analyzing the caching strategy 
flags related to the response. 

66. The system of claim 61 wherein each part has one or 
more attributes characteriziog the part, the attributes indi- 
cating the cacheability of the part, wherein the response 
builder comprises an attribute analyzer for creating a com- 
posite set of attributes based upon the individual attributes of 
the individual parts, the composite attribute set providing a 
characterization of the cacheability of the response; and 
further wherein the cacheability analyzer examines the 
attribute composite set lo determine cacheability of the 
response. 

67. The system of claim 61 wherein the cadieability 
analyzer creates a caching strategy comprising a plurality of 
flags. 

68. The system of claim 67 wherein each request has odc 
or more properties, wherein the caching strategy comprises 
at least one flag indicating that the response is cacheable and 
at least one flag indicating that the applicability of the 
response for serving to subsequent requests is based upon 
the one or more properties of the subsequent request. 

69. The system of claim 67 wherein the caching strategy 
comprises at least one flag indicating that the response is 
cacheable but its validity is based upon whether any of the 
parts on the one or more sources has been modified since the 
response has been cached. 

70. The system of claim 61 wherein the cacheabflity 
analyzer analyzes the attributes to determine whether any of 
the attributes indicate that the response causes important 
side effects and makes a determination that the response is 
not cacheable if any of the attributes indicate that the 
response causes important side effects. 
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71. The system of claim 61 wherein the cacheability 
analyzer analyzes the attributes to determine whether any of 
the attributes indicate that the response \ises time variant 
data and makes a determination that the response is only 

5 cacheable for a determined length of time if any of the 
attributes indicate that the response uses time variant data. 

72. The system of claim 61 wherein the cacheability 
analyzer further comprises means for creating a caching 
strategy comprising a plurality of flags, and further wherein 
the means for caching caches the caching strategy flags 
along with the associated response. 

73. A method for use in a system which receives a request 
from a requestor and serves a response to that request, the 
response comprising a composite of the one or more parts, 
at least one of the parts comprising dynamic content, the 
system having a cache for holding previously served cached 
responses, each of the cached responses having an address, 
the method comprising the steps of: 

a) receiving a request from a requestor; 

b) compariog the request against the cached response and 
for identifying a candidate cached response; 

c) determining whether the candidate cached response 
should be served to the request; 

d) if so, serving the cached response; 

25 e) if not, building a new response to the request; 

f) analyzing the built response and determining its 
cacheability, wherein the cacheability is determined 
based on at least one of a time variance setting of 
dynamic content, a user's identity, and a location of 

30 dynamic content; 

g) caching, in the cache, the response based upon that 
cacheability determination; and 

h) serving the response or candidate cached response to 
the request. 

35 74. The method of claim 73 wherein step c furUier 
comprises determining the applicability of the candidate 
cached response to the request and determining the validity 
of the candidate cached response and step d further com- 
prises serving the candidate cached response if the candidate 

40 cached response is both applicable and valid. 

75. The method of claim 74 wherein the request has 
request properties, one of the request properties being a 
requestor identity, wherein the applicability analyzing step 
comprises determining whether the candidate cached 

45 response is applicable for serving to the request based upon 
the requester identity. 

76. The method of claim 73 wherein the one or more parts 
are from one or more sources and wherein the parts of each 
candidate cached response each has a last modified date, 

50 wherein step c further comprises comparing the parts of each 
candidate cached response last modified dates to the last 
modified dates of the parts comprising response on the one 
or more sources. 

77. The method of claim 73 wherein each part has one or 
55 more attributes characterizing the part, the attributes indi- 
cating the cacheability of the part, wherein step e further 
comprises the step of creating a composite set of attributes 
based upon the individual attributes of the individual parts, 
the composite attribute set providing a characterization of 

60 the cacheabflity of the response; and further wherein step f 
comprises the step of examining the attribute composite set 
to determine cacheabflity of the response. 

78. The method of claim 73 wherein step f further 
comprises creating a caching strategy comprising a pluraKty 

65 of flags. 

79. The method of claim 78 wherein each request has one 
or more properties, wherein the caching strategy comprises 
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at least one flag indicating that the response is cacheable and 86. The computer usable medium of claim 84 wherein the 

at least one flag indicating that the applicability of the request has request properties, one of the request properties 

response for serving to subsequent requests is based upon being a requestor identity, wherein the applicabihty analyz- 

the one or more properties of the subsequent request. ing step comprises determining whether the candidate 
SO.Themethodof claim 77 wherein the caching strategy 5 cached response is applicable for serving to the request 

comprises at least one flag indicating that the response is ^ased upon the requestor identity 

cacheable and its validity is based upon whether any of the ^he computer usable medium of claim 83 wherein the 

^tT nL has been crcher'"^' '^'''^^^'^ ^^"^ °' "^""'^ ^^"^ ^"^"^ ""^'^ ^^"'"^^ 

response as een cac e * . the parts of each candidate cached response each has a last 

81. The method of claim 77 wherem step f further lO Iti^A a - * *u 

comprises the steps of analyzing the attributes to determine ^ I t""'"'^-. ? ' ua' """""^"T '""""^.T! 

whether any of the attributes indicate that the response ^ parts of each candidate cached response last modified 

causes important side effects and making a determination ^^^^^ ^^^^ "^^^^^'^ ^^^^^ comprismg the 

that the response is not cacheable if any of the attributes response on the one or more sources, 

indicate that the response causes important side effects. 15 computer usable medium of claim 84 wherein 

82. The method of claim 73 wherein step f further ^^ch part has one or more attributes characterizing the part, 
comprises the steps of analyzing the attributes to determine attributes indicating the cacheability of the part, wherein 
whether any of the attributes indicate that the response uses step e further comprises the step of creating a composite set 
time variant data and making a determination that the of attributes based upon the individual attributes of the 
response is only cacheable for a determined length of time 20 individual parts, the composite attribute set providing a 
if any of the attributes indicate that response uses time characterization of the cacheabUity of the response; and 
variant data. further wherein step f comprises the step of examining the 

83. The method of claim 77 wherein step g comprises attribute composite set to determine cacheabiUty of the 
caching the caching strategy flags along with the associated response. 

response. 25 g9. The computer usable medium of claim 84 wherein 

84. A computer usable medium for use in a computer step f further comprises creating a caching strategy com- 
which receives a request from a requester and serves a prising a plurality flags 

response to that request, the response comprising a compos- 90. The computer usable medium of claim 89 wherein 

ite of the one or more parts at least one of the parts each request has one or more properties, wherein the caching 

compnsmg dynamic content, the computer having a cache 30 . . • < 1 * a • *• 4i_ * ^i. 

c il Aj,^ ' , J t. c X. strategy compnses at least one flag mdicatmg that the 

for holding previously served cached responses, each of the . 1. .1 j ,1 ^ % ■ ..1. 

,j ' response is cacheable and at least one flag mdicatme that the 

cached responses having an address, the computer usable i- r o • . f 

medium having computer readable program code embodied apphcability of the response for servmg to subsequent 

in the medium for causing the computer to perform method ^^^""^ ^P"'^ properties of the 
steps of: 35 subsequent request. 

2l) receivin a re uest from a re uesto computer usable medium of claim 89 wherein the 

a; receiving a reques rom a reques or, caching strategy comprises at least one flag indicating that 

b) comparing the request against the cached response and the response is cacheable and its validity is based upon 
for identifying a candidate cached response; whether any of the parts on the one or more sources has been 

c) determining whether the candidate cached response modified since the response has been cached. 

should be served to the request; 92. The computer usable medium of claim 84 wherein 

d) if so, serving the cached response; step f further comprises the steps of analyzing the attributes 

e) if not, building a new response to the request; ^« determine whether any of the attributes indicate that the 
* 1 ... .1. , 1 . . . . response causes important side effects and making a deter- 

f) andyzing the built response imd determining its ^^^^^^ jj,^, ^ ^^^j^^^^le if any of the 
cacheabiUty, wherem the cacheabihty is deterrained 45 ^^^.^^^^ .^^.^^^ ^^^^ ^ ^^^^^ ^ ^^^ ^.^^ 
based on at least one of a time variance setting of effects 

dynamic content, a user's identity, and a location of 93 ^^^^^^^ ^^^^^ ^^^^^ ^^^^ ^ ^^^^^^ 

ynamic con en , ^^^p ^ further comprises the steps of analyzing the attributes 

g) caching, in the cache, the response based upon that to determine whether any of the attributes indicate that 
cacheability determination; and response uses time variant data and making a determination 

h) serving the response or candidate cached response to that the response is only cacheable for a determined length 
the request. of time if any of the attributes indicate that response uses 

85. The computer usable medium of claim 84 wherein time variant data. 

step c further comprises determining the apphcability of the 94, The computer usable medium of claim 89 wherein 

candidate cached response to the requestor and determining step g comprises caching the caching strategy flags along 

the vahdity of the candidate cached response and step d with the associated response, 
further comprises serving the candidate cached response if 

the candidate cached response is both applicable and valid. ***** 
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